Use mixed-radix decompositions for CurveFFT - #166

Follow-up CurveFFT kernel experiments (2026-08-23)

I evaluated the remaining kernel ideas on top of this PR. None of items 1-7
survived balanced benchmark-server validation, so the PR remains unchanged.

1. Fuse fixed-scalar groups into one heterogeneous affine ladder. A
   generic pair fusion was 1-5% slower locally. Dedicated three- and
   four-group scalar-run kernels, which decoded each scalar only once, were
   still 1-3% slower. The existing tight same-scalar loops beat the saved
   divstep inversions.
2. Two-chain the L+R/L-R batch inversion. Correct, but isolated Mac runs
   were 0.5-1% slower. Linux direction changed with host drift, and the
   combined candidate was statistically flat. Rejected.
3. Stage the complete L+R/L-R finishing formula. Correct, including the
   Apple paired field-multiplication path, but flat to slightly slower because
   of the extra structure-of-arrays memory passes. Rejected.
4. Retain reusable DFT8/DFT16 intermediate scratch. About a 0.5% local
   trend at k=11 and flat at k=13. In combination with item 2 it measured
   approximately 0-0.5% on the Macs and mixed within 1% on Linux. Rejected as
   noise-sized.
5. Replace diagonal Vec grouping with a flat counting layout. Both a
   preinitialized point buffer and a flat entry/order variant were 1-2%
   slower. The current small, one-pass groups are more cache-friendly.
6. Fuse routing with codelet I/O. Fusing the initial gather was about 2.5%
   slower at k=11; strided final writes were 3-4% slower. The explicit
   transpose is doing useful cache organization.
7. Change factor order. The three k=11 orders and the extreme k=13
   placements were indistinguishable. The canonical order stays.

Item 8 was kept on a separate experimental branch as requested:
optimize-dft32-curvefft (unpublished as a PR).

• The split DFT32 is correct on both Pasta curves and costs 42 point-scalar
  multiplications versus 43 for DFT16 plus radix-2.
• At k=13, factors 32 x 16 x 16 execute 40,193 point-scalar
  multiplications, down 256 (0.63%) from this PR's 40,449, down 3,328 from
  the previous codelet schedule, and down 4,864 from plain radix-2
  Cooley-Tukey (45,057).
• It adds 512 curve additions (116,224 versus 115,712), keeps 2,938 distinct
  twiddle decompositions, and reduces layout traffic from 6N to 4N.
• The simple composition has 24 sequential affine-addition inversion batches
  for the full k=13 schedule versus 18 here. A fused prototype reduced that
  to 20, but did not improve server performance and was reverted.
• Balanced single-core centers versus this PR were approximately -0.7%,
  -0.9%, -0.9%, and +0.2% on macOS-1, macOS-2, Linux-1, and Linux-2.
• Multicore was architecture-dependent: about 1.5-1.6% faster on both Macs,
  but repeatable reverse-order runs were 2.5-3.0% slower on both Linux hosts.

Because DFT32 regresses portable multicore performance, I did not open the
separate stacked PR. The experimental branch preserves both the correct
prototype and the rejected fusion history for future work.